home *** CD-ROM | disk | FTP | other *** search
/ 8bitfiles.net/archives / archives.tar / archives / compuserve-file-archive / 12 C64 Telecom / PORTPR.DOC < prev    next >
Encoding:
Text File  |  2019-04-13  |  4.2 KB  |  86 lines
  1. Notes on portprn.img
  2.  
  3. Portprn.img is a machine language routine.  Load it ,8,1 and SYS 4096 ($1000)
  4. The STOP key will break it at any time.
  5.  
  6. The idea behind this program is a fairly simple one:  The C64 accepts input,
  7. one line at a time, over the user port to which is connected an RS 232
  8. interface.  It translates the input from pure ascii into petscii as the data
  9. is received, and then prints it to a printer (device 4) on the bus.  I went
  10. to this effort because I bought a second computer, which has a serial
  11. interface, and did not want to spend money on another cheap dot-matrix
  12. printer.  The 1526 is a perfectly sound, if not lightning fast, text
  13. printer.  The setup serves my purposes, kludgy or not.  Although I have had
  14. problems getting it to work with a screen dump, it works fine when printing
  15. under program control.
  16.  
  17. Screen notes:
  18.  
  19. The screen shows the status of both the (serial printer) bus and the (RS 232
  20. user) port.  The checkmarks indicate the state (open/closed) of each.  In
  21. addition, the error codes are read and sent to the screen as characters.
  22. Error checking per se is not done, rather, the results in the Accumulator or
  23. in the status byte are sent -- good, bad, or indifferent -- straight to the
  24. screen.  It's a lazy way out, but if things aren't working, at least the
  25. codes are there to be analyzed.  They are in the following order:
  26.  
  27. RS 232 Status
  28.    open:  Error result in Accumulator and readst byte from kernal OPEN
  29.    init:  Error result in Accumulator from kernal CHKIN
  30.    close: blank; never closed.
  31.  
  32. Printer Status
  33.    open:  Error result in Accumulator from kernal OPEN
  34.    init:  Error result in Accumulator and readst byte from kernal CHKOUT
  35.    close: Readst byte from kernal UNLSN, error result in Accumulator  and
  36.           readst byte from kernal CLOSE
  37.  
  38. Of course, what you see are the screen codes (PRG Appendix B).
  39.  
  40. Programming notes:
  41.  
  42. The RS 232 interface is set at 1200 bps, even parity, seven data bits, one
  43. stop bit.  The x-line handshake is implemented, although the port buffer is
  44. almost always empty when operating at ML speeds.
  45.  
  46. Alphanumeric and punctuation characters are translated; carriage return and
  47. form feeds are fed straight to the printer.  All others, including tabs and
  48. linefeeds, are stripped.
  49.  
  50. This is only significant ML program I have ever written.  I prefer
  51. compilers, but because Oxford Pascal does not recognize the user port at
  52. all, this seemed a natural application.  The source code is commented and
  53. makes liberal use of symbols as I made notes to myself along the way.  It
  54. was originally supposed to be a spooler, but that seems to be impractical
  55. for reasons outlined below.  My choice of location was purely arbitrary and
  56. probably less than ideal.  It wouldn't be very difficult to change, were you
  57. so inclined, by re-assembling with a different origin.  I used the EA
  58. assembler by Lew Lasher available (or was) on this SIG.  The buffered line
  59. is stored at $7000, and probably should be moved closer to the code, I
  60. guess.
  61.  
  62. I don't pretend that it is the most elegant code ever written, but I think
  63. it may serve as a starting point if you are thinking of writing a
  64. communications program, or have a situation similar to mine.  I have read
  65. three books on ML programming, including both of Richard Mansfield's highly
  66. acclaimed volumes.  Helpful as they were, communications I/O was not in any
  67. of them.  Nobody discusses the difference between CHROUT and CIOUT, for
  68. instance, and for me there was a lot of trial and error.  For this reason,
  69. it is my hope that the source code will be instructive.
  70.  
  71. Why not a spooler?  Both the bus and the port communicate bit-by-bit (no pun
  72. intended).  Assembly/disassembly of the BYTES used within the C64 to the
  73. BITS it needs to communicate is done in zero page by the CPU.  Our friend
  74. the 6510 does one thing at a time, does it very well, and then goes on (like
  75. Major Winchester).  Ergo, it cannot address both the port and the bus at the
  76. same time, as they need the same ZP routines.  This limitation made it
  77. necessary (as I understand it) to close the bus down completely when
  78. printing.
  79.  
  80. Hardware note:
  81.  
  82. I constructed a null modem cable crossing pins 2/3, 4/5, 6/20. Crossing 5/20
  83. should work as well.  The software drops DTR (20) when it receives a
  84. carriage return, causing the sending machine to hold off.
  85.  
  86.